1. Technical Field of the Invention
The present invention relates to communications systems and, in particular, to the specification of Transaction Capability Application Part (TCAP) package types for ANSI-41 messages in order to support the closure of open Mobile Application Part (MAP) operations.
2. Description of Related Art
Reference is now made to FIG. 1 wherein there is shown a signal flow and nodal operation diagram illustrating prior art ANSI-41 messaging sharing the same Transaction Capability Application Part (TCAP) transaction identifier. This illustrated example of shared TCAP transaction identifier ANSI-41 messaging relates to the use of the remote user interaction directive (RUIDIR) message in connection with the implementation of a password call acceptance (PCA) service feature. An incoming call 100 dialed to the directory number of a certain mobile station (not shown) is received at an originating (gateway) mobile switching center (MSC) 102 within a mobile (cellular) communications network. Responsive to the received call, the originating mobile switching center 102 sends an ANSI-41 MAP location request (LOCREQ) message 104 to a home location register (HLR) 106 for that called mobile station, and starts a LOCREQ timer. This location request message 104 initiates a TCAP transaction 108, and includes a package type identifier of "query with permission". Responsive to the location request message 104, the home location register 106 determines (action 110) from the stored service profile for the called mobile station that the password call acceptance (PCA) service feature is active, and starts a user interactive session. A MAP remote user interaction directive (RUIDIR) message 112 is accordingly sent by the home location register 106 back to the originating mobile switching center 102. This remote user interaction directive message 112 is included as part of the same TCAP transaction 108, and includes a package type identifier of "conversation without permissions. On receipt of the remote user interaction directive message 112, the originating mobile switching center 102 turns off the LOCREQ timer and provides the call treatment as indicated in the remote user interaction directive message. For the password call acceptance service feature this treatment includes prompting 114 and 116 the calling party (not shown) in accordance with the remote user interaction directive message 112, and waiting for the calling party to enter password digits. The calling party then responds with password digits 118. The originating mobile switching center 102 then sends a remote user interaction directive return message (ruidir) 120 containing the entered password digits back to the home location register 106. This remote user interaction directive return message 120 is included as part of the same TCAP transaction 108, and includes a package type identifier of "conversation with permission". The home location register 106 then compares (action 122) the entered password digits against a screening list. In this particular example, it is assumed that the entered password digits do not match an entry on the screening list. This means that the incoming call 100 is not to be allowed to proceed to completion. Instead, the incoming call 100 is to be forwarded to a voice mail system. The home location register 106 then sends a location request return result message (locreq) 124, including a directory number for the voice mail system, back to the originating mobile switching center 102. This location request return result message 124 is included as part of the same TCAP transaction 108, and includes a package type identifier of "response". The originating mobile switching center 102 then provides call treatment (action 126) to the incoming call 100 in accordance with the instructions contained in the location request return result message 124. Treatment in this case may include the provision of an announcement indicating that an incorrect password was provided. The incoming call 100 is then forwarded 128 to the voice mail system 130. It is noted that in the foregoing calling scenario, both of the LOCREQ and RUIDIR MAP operations were successfully completed by the end of the TCAP transaction 108.
Reference is now made to FIG. 2 wherein there is shown a signal flow and nodal operation diagram illustrating prior art ANSI-41 messaging wherein a location request operation is not completed within a shared (nested) TCAP transaction. Again, this illustrated example presents call handling in connection with the implementation of a password call acceptance service feature. An incoming call 100 dialed to the directory number of a certain mobile station (not shown) is received at an originating (gateway) mobile switching center 102 within a mobile (cellular) communications network. Responsive to the received call, the originating mobile switching center 102 sends an ANSI-41 MAP location request (LOCREQ) message 104 to a home location register 106 for that called mobile station, and starts a LOCREQ timer. This location request message 104 initiates a TCAP transaction 108, and includes a package type identifier of "query with permission". Responsive to the location request message 104, the home location register 106 determines (action 110) from the stored service profile for the called mobile station that the password call acceptance (PCA) service feature is active, and starts a user interactive session. A MAP remote user interaction directive (RUIDIR) message 112 is accordingly sent by the home location register 106 back to the originating mobile switching center 102. This remote user interaction directive message 112 is included as part of the same TCAP transaction 108, and includes a package type identifier of "conversation without permission". On receipt of the remote user interaction directive message 112, the originating mobile switching center 102 turns off the LOCREQ timer and a problem (event 132) is thereafter detected. This problem may involve, for example, a resource shortage or a parameter error. Due to this problem, the remote user interaction directive message 112 cannot be processed. The originating mobile switching center 102 then sends a remote user interaction directive return error (or reject) message (ruidir error) 134 back to the home location register 106. This remote user interaction directive return error message 134 is included as part of the same TCAP transaction 108, and includes a package type identifier of "response". In this scenario, the specified package type identifier of "response" for the remote user interaction directive return error message 134 causes a premature termination of the TCAP transaction 108 without the home location register 106 providing an answer to the location request message 104 (i.e., no closure of the LOCREQ MAP operation). It should be recognized here that a response is not a valid reply to a conversation without permission package type. The originating mobile switching center 102 is accordingly not able to properly handle or redirect the incoming call 100 (for example, to the voice mail system 130 as in FIG. 1). Action may eventually be taken by the originating mobile switching center 102 as time supervision for the LOCREQ operation expires, but none of these possible actions depend on information provided by the home location register 106. There is a need for a mechanism to support LOCREQ MAP operation closure and allow the home location register to provide an answer.
Reference is now made to FIG. 3 wherein there is shown a signal flow and nodal operation diagram illustrating prior art ANSI-41 messaging wherein an instruction request operation is not completed within a shared (sequential) TCAP transaction. A mobile switching center 200 sends a MAP origination request (ORREQ) message 202 to a service control function (SCF) 204. Responsive to the origination request message 202, the service control function 204 sends a MAP seize resource (SEIZRES) message 206 to an intelligent peripheral (IP) 208. This seize resource message 206 initiates a TCAP transaction 210, and includes a package type identifier of "query with permission". Responsive to the seize resource message 206, the intelligent peripheral 208 seizes (action 212) the appropriate resources and sends a seize resource return result message (seizres) 214 back the service control function 204. This seize resource return result message 214 is included as part of the same TCAP transaction 210, and includes a package type identifier of "conversation without permission". A MAP connect resource (CONNRES) message 216 is then sent from the service control function 204 to the mobile switching center 200, and a connection 218 is set-up between the mobile switching center and the intelligent peripheral 208. The intelligent peripheral 208 next sends a MAP instruction request (INSTREQ) message 220 to the service control function 204. This instruction request message 220 is included as part of the same TCAP transaction 210, and includes a package type identifier of "conversation without permission". On receipt of the instruction request message 220, the service control function 204 detects a problem (event 222). This problem may involve, for example, a resource shortage or a parameter error. Due to this problem, the instruction request message 220 cannot be processed. Furthermore, because the instruction request message 220 includes a package type identifier of conversation without permission", the service control function 204 is not permitted to send an instruction request return error (or reject) message (instreq error) with a proper ANSI-41 package type back to the intelligent peripheral 208. In this scenario, the specified package type identifier of "conversation without permission" for the instruction request message 220 prevents the service control function 204 from being able to properly terminate (i.e., close) the INSTREQ MAP operation. There is a need for a mechanism to support INSTREQ operation closure and allow the service control facility to answer.
More generally, there is a need in situations where a TCAP transaction with nested MAP operations is instigated to not only allow for the closure of the outer MAP operation, but also allow a node implicated by the nested operations to respond with a final instruction in situations where inner MAP operation messaging is unsuccessful. Furthermore, there is a need in situations where a TCAP transaction with sequential MAP operations is instigated to allow for the closure of each MAP operation, and allow a node implicated by the sequential operations to respond with a final instruction when MAP operation messaging is unsuccessful.